Forum des exercices du projet Zuul

Revenir à Généralités

Exercice 7.28.3 (OPTIONNEL)

Vous êtes abonné à cette discussion. Cliquez pour vous désabonner.Abonné
  
 
Avatar anonfirstname2 anonlastname2
Exercice 7.28.3 (OPTIONNEL)
par anonfirstname2 anonlastname2, lundi 18 février 2013, 18:25
 

Prévoir des mécanismes permettant de spécifier ce qui est attendu à l'issue d'une commande et de vérifier que c'est bien le cas. Par exemple, "est-on au bon endroit ?" ou "tel item est-il bien présent ?".

Cet exercice nécessite un investissement en temps, mais cela peut s'avérer payant pendant la suite du projet, puisqu'il permettra après chaque modification du code (et il va y en avoir des grosses !) de vérifier que le jeu continue de fonctionner parfaitement, et sinon, de détecter les problèmes au plus tôt.

 
Permalien | Modifier | Supprimer | Répondre
Avatar Denis BUREAU
Re: Exercice 7.28.3 (OPTIONNEL)
par Denis BUREAU, jeudi 12 mars 2020, 07:01
 

Un étudiant a écrit :

Je ne comprends pas bien ce qui est demandé dans l'exercice.
Faut il rajouter un procédure pour vérifier les déplacement du joueur? 
Ou juste vérifier certaine méthode après que le joueur l'ai tapé? 

 
Permalien | Niveau supérieur | Modifier | Séparer | Supprimer | Répondre
Avatar Denis BUREAU
Re: Exercice 7.28.3 (OPTIONNEL)
par Denis BUREAU, jeudi 12 mars 2020, 07:21
 

Cet exercice optionnel part du constat qu'après avoir exécuté la commande test, vous devez vérifier les différents affichages pour savoir si tout s'est bien déroulé.

Il est donc possible qu'un problème vous échappe ou même que vous n'ayez pas le courage de tout vérifier à chaque fois que vous devez exécuter la commande test (c'est-à-dire après chaque exercice entraînant une modification du code).

On peut donc essayer d'imaginer des solutions (dont une syntaxe pour les fichiers de test) pour que la commande test soit en mesure de vérifier des choses automatiquement après l'exécution de chaque commande qu'elle exécute.

Par exemple pour la commande go, si après son exécution on se retrouve bien dans la bonne pièce. Ou par exemple pour la future commande take, si après son exécution l'item a bien disparu de la pièce et se retrouve bien dans l'inventaire du joueur.

Sans que ce soit prescriptif, voici ce qu'un fichier de test pourrait contenir :

...
roomis entree
go north
roomis cuisine
roomhas couteau
take couteau
roomhasnot couteau
playerhas couteau
...

 
Permalien | Niveau supérieur | Modifier | Séparer | Supprimer | Répondre
Avatar Denis BUREAU
Re: Exercice 7.28.3 (OPTIONNEL)
par Denis BUREAU, mercredi 29 mars 2023, 17:01
 

Un étudiant a écrit :

Je ne comprend pas comment il est possible de tester si un message à bien été affiché correctement.
Exemple tester la méthode look item et vérifier que c'est bien le bon item qui a été affiché.
Comment faire comprendre à une Exception que l'item affiché n'est pas le bon par exemple.
Pour tester si l'on est dans la bonne Room après un goRoom ne pose pas de problème, à la limite je fais une méthode booléenne qui renvoie false si c'est la mauvaise room, mais tester un message...

 
Permalien | Niveau supérieur | Modifier | Séparer | Supprimer | Répondre
Avatar Denis BUREAU
Re: Exercice 7.28.3 (OPTIONNEL)
par Denis BUREAU, jeudi 30 mars 2023, 08:21
 

Vous avez raison, c'est plus difficile, c'est pourquoi ce n'était pas demandé ci-dessus.
Ce n'est pas impossible non plus : on pourrait imaginer qu'une procédure println dans GameEngine mémorise la String à afficher avant d'appeler this.aGui.println . Cela permettrait ensuite de tester cette String...

 
Permalien | Niveau supérieur | Modifier | Séparer | Supprimer | Répondre